| Create a unique number on the server | Create a unique number on the device | ||
|
Pros Guarantees uniqueness throughout system - no duplication of numbers between devices Centralised numbers Guarantees no gaps in sequential numbers as report is completed before generation |
Cons Not available on the device in real-time Device needs a signal Delay while data transfers to server & number is generated |
Pros Available in real-time Easily uses user/device specific data as prefix Easily include customer data as prefix Starting number selected by user (gives control) Device user can give reference to customer immediately |
Cons No guarantee of uniqueness Starting number selected by user (potential duplication) Customer's reference may not be unique Gaps may occur if forms are discarded after number has been generated |
We usually advise generating unique codes or numbers on the server. This guarantees uniqueness because each request goes through the same point one at a time so there’s no chance of numbers being allocated at the same time.
However, this means that the number isn’t available on the device as the form is being completed. The number is allocated by a “service” that runs in the background on the server, and this means that there may be delay of a few minutes - not usually a problem but it doesn't show up on the portal immediately so you may need to refresh the page.
Also, if the server is generating the number then the device user needs a signal. Plus there’s not any guarantee about how quickly the number will be generated when a form is received (although it’ll usually just be a minute or so).
Therefore, the server route is best for allocating system-wide numbers, but it’s not real-time if the end user needs the number straightaway.
If you go down the device-allocated number route then you’re never going to have 100% guarantee of uniqueness. You can generate a sequential number on the device and the “seed” number for this is specified when the first number is allocated – but users can potentially override this and put the wrong seed number in (and you can’t take this ability away from them otherwise the seed number will always be 1 or whatever).
Despite this limitation about people potentially causing the software to generate the wrong sequence number, it’s often a good solution. And you can prefix the sequential number with a user specific code (eg. initials).
Therefore we sometimes recommend using both:
- On the device have a user-specific, incrementing number which the user gives as their reference to the person that they’re with
- On the server generate the real unique number
- The number in (1) is usually sufficient as a reference for customer (along with things like date and time etc)
With the “seed” (starting) numbers it’s often possible to give users their own values. This is prompted for the first time a number is generated (add in a “Calculated value” item and in the calculation put something like $seq:PORef). User 1 is told to put in 10000, user 2 20000 etc. The problem is that if the app is uninstalled then they have to re-specify it and they might not remember where they got up to.
Also consider whether gaps are an problem – the server route ensures that there won’t be, but the with the device option it is always the possibility.
If we could assume that the user has a signal then it might be possible to have a “web service” or something where they tap a button and it goes off and gets the next number. Or (not as good) they submit one form to get a number, wait a few minutes for the server to update and then do an update to view the generated number.
list.